-
Notifications
You must be signed in to change notification settings - Fork 24.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MetaData Builder doesn't properly prevent an alias with the same name as an index #26804
Conversation
… of index Elasticsearch doesn't allow having an index alias named with the same name as an existing index. We currently have logic that tries to prevents that in the `MetaData.Builder#build()` method. Sadly that logic is flawed. Depending on iteration order, we may allow the above to happen (if we encounter the alias before the index). This commit fixes the above and improves the error message while at it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for fixing this! I left some comments
} | ||
assert duplicates.size() > 0; | ||
throw new IllegalStateException("index and alias names need to be unique, but the following duplicates were found [" | ||
+ Strings.join(duplicates, ", ")+ "]"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should be Strings.collectionToCommaDelimitedString
and then you can use our Strings.java instead of JOpt's version
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
woops. Good catch
|
||
List<String> allOpenIndicesLst = new ArrayList<>(); | ||
List<String> allClosedIndicesLst = new ArrayList<>(); | ||
final Set<String> allIndices = new HashSet<>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor nit, this can be new HashSet<>(indices.size())
} | ||
} | ||
} | ||
assert duplicates.size() > 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps add the duplicate size to the assert message here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's 0 ? :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
whoops I read it backwards, so yeah, not really necessary
final Set<String> allIndices = new HashSet<>(); | ||
final List<String> allOpenIndices = new ArrayList<>(); | ||
final List<String> allClosedIndices = new ArrayList<>(); | ||
final Set<String> duplicateAliasesIndices = new HashSet<>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can just be named allAliasNames
since it's just a set of the alias names, the "duplicate" part was throwing me off
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I started that way, but since Java doesn't have a normal non set modifying set difference I had to mutate this set. I felt it's dangerous to just call it allAliases
and then essentially make it empty.
|
||
// build all indices map | ||
SortedMap<String, AliasOrIndex> aliasAndIndexLookup = new TreeMap<>(); | ||
for (ObjectCursor<IndexMetaData> cursor : indices.values()) { | ||
IndexMetaData indexMetaData = cursor.value; | ||
aliasAndIndexLookup.put(indexMetaData.getIndex().getName(), new AliasOrIndex.Index(indexMetaData)); | ||
AliasOrIndex exiting = aliasAndIndexLookup.put(indexMetaData.getIndex().getName(), new AliasOrIndex.Index(indexMetaData)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
exiting -> exists
} else { | ||
throw new IllegalStateException("unexpected alias [" + aliasMetaData.getAlias() + "][" + aliasOrIndex + "]"); | ||
assert alias instanceof AliasOrIndex.Alias : alias.getClass().getName(); | ||
((AliasOrIndex.Alias) alias).addIndex(indexMetaData); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this would be cleaner as
aliasAndIndexLookup.compute(aliasMetaData.getAlias(), (aliasName, alias) -> {
if (alias == null) {
return new AliasOrIndex.Alias(aliasMetaData, indexMetaData);
} else {
((AliasOrIndex.Alias) alias).addIndex(indexMetaData);
return alias;
}
});
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sure
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
thx @dakrone |
… as an index (#26804) Elasticsearch doesn't allow having an index alias named with the same name as an existing index. We currently have logic that tries to prevents that in the `MetaData.Builder#build()` method. Sadly that logic is flawed. Depending on iteration order, we may allow the above to happen (if we encounter the alias before the index). This commit fixes the above and improves the error message while at it. Note that we have a lot of protections in place before we end up relying on the metadata builder (validating this when we process APIs). I takes quite an abuse of the cluster to get that far.
… as an index (#26804) Elasticsearch doesn't allow having an index alias named with the same name as an existing index. We currently have logic that tries to prevents that in the `MetaData.Builder#build()` method. Sadly that logic is flawed. Depending on iteration order, we may allow the above to happen (if we encounter the alias before the index). This commit fixes the above and improves the error message while at it. Note that we have a lot of protections in place before we end up relying on the metadata builder (validating this when we process APIs). I takes quite an abuse of the cluster to get that far.
… as an index (#26804) Elasticsearch doesn't allow having an index alias named with the same name as an existing index. We currently have logic that tries to prevents that in the `MetaData.Builder#build()` method. Sadly that logic is flawed. Depending on iteration order, we may allow the above to happen (if we encounter the alias before the index). This commit fixes the above and improves the error message while at it. Note that we have a lot of protections in place before we end up relying on the metadata builder (validating this when we process APIs). I takes quite an abuse of the cluster to get that far.
* xdcr: Maybe die before trying to log cause Log cause when a write and flush fails Die if write listener fails due to fatal error RecoveryIT.testHistoryUUIDIsGenerated should reduce unassigned shards delay instead of ensure green. Replace group map settings with affix setting (elastic#26819) Fix references to vm.max_map_count in Docker docs Add more instructions about jar hell (elastic#26837) Forbid negative values for index.unassigned.node_left.delayed_timeout (elastic#26828) Nitpicking typos in comments (elastic#26831) MetaData Builder doesn't properly prevent an alias with the same name as an index (elastic#26804)
Elasticsearch doesn't allow having an index alias named with the same name as an existing index. We currently have logic that tries to prevents that in the
MetaData.Builder#build()
method. Sadly that logic is flawed. Depending on iteration order, we may allow the above to happen (if we encounter the alias before the index).This commit fixes the above and improves the error message while at it.
Note that we have a lot of protections in place before we end up relying on the metadata builder (validating this when we process APIs). I takes quite an abuse of the cluster to get that far.